A virtual machine architecture logically partitions a physical machine, such that the underlying hardware of the machine is time-shared and appears as one or more independently operating virtual machines (VMs). A virtual machine monitor (VMM) runs on a computer to facilitate for other software the abstraction of one or more VMs. Each VM may function as a self-contained platform, running its own operating system (OS) and application software. The software running in a VM is collectively referred to herein as “guest software.”
A VMM environment provides hardware and system-control instructions that enable software running on an actual system to provide an almost-perfect emulation of a virtual system or VM for guest software. Benefits of such environments include, for example, the ability to run multiple operating systems on a single physical machine; improved utilization of CPU and hardware resources.
Virtualization technology allows a platform to support running of multiple partitions over a single machine or computing system (or environment). These partitions are isolated from each other, providing the advantage of increased robustness. The partitions run on top of a VMM, which may be described as a software virtualization layer that has a “real view” of the platform resources, such as the memory. Thus, this real view of memory may be described as the “host physical addresses” or HPAs (e.g., host addresses). Each partition or VM has a “virtualized view” of memory, which may be described as “guest physical addresses” or GPAs.
The guest software expects to operate as if it were running on a dedicated computer rather than in a VM. That is, the guest software expects to control various events and have access to hardware resources on the computer (e.g., physical machine). The hardware resources of the physical machine may include one or more processors, resources resident on the processors (e.g., control registers, caches and others memory (e.g., instructions and/or data residing in memory at addresses, such as graphics instructions and/or data), graphics devices and/or controllers (e.g., graphics circuits, graphics chipsets, graphics cards, etc.), and other resources (e.g., input/output devices) that reside in the physical machine. The events may include rendering and displaying graphics data to display graphics images in a VMM environment. Such images can include pixel images, encoded images, video images or frames, static images, photo images, animated images, movies, etc.
Hence, a VMM presents to other software (“guest software,” “guests” or simply “guest”) the abstraction of one or more VMs. The VMM can provide the same or different abstractions to the various guests. Each guest expects the full facilities of the hardware platform presented in the VM to be available for its use. For example, the guest expects to have access to all registers, caches, structures, I/O devices, memory, graphics devices/controllers and the like according to the architecture of the processor and platform presented in the VM. Further, each guest may expect the VMM to handle various events, such as by handling a guest's graphics instructions (e.g., including graphics addresses) and/or data to display graphics images on a display or monitor.
For instance, in some cases a VMM may depend on virtualization of devices for input/output (IO) device support. Typically, the IO devices are virtualized by the VMM and the VMM directly controls the actual hardware on the platform. In these cases the VMM emulates the IO devices that are exposed to the VM. Since the VMM directly communicates with the hardware, the VMM carries the drivers for all of the devices supported. Carrying all of the drivers causes the VMM code or software to bloat or have an undesirably large amount of code leading to increased complexity.